With the continual growth of the world wide web and the growing reliance of businesses on the world wide web for interacting with other businesses and with individuals, a services-oriented architecture has been utilized to help information technology (IT) groups integrate existing backend applications, for example, with new and other front end applications. Services-oriented architecture is a term describing an architecture supporting the provision of services which are performed by groups of software components that carry out business processes such as verifying a credit card transaction or processing a purchase order. At its most basic level, a services-oriented architecture defines a collection of services on a network such as the Internet that communicate with one another to accomplish a specific task. Typically, the services are loosely coupled, have well-defined platform-independent interfaces, and are re-usable.
Services-oriented architecture is an abstract concept which describes a higher level of software application development which focuses on business processes and standard interfaces to mask out the technical complexity of the underlying IT environment. Such a higher level abstraction allows services provided by different businesses to be utilized by an application developer. For example, services may include a time of day service which provides time based on the United States' atomic clock and a weather service which provides weather information for various regions of the United States. Services are well-defined, self-contained, and do not depend on the context or state of other services. The application developer may add time of day and weather services to his or her application without having to know the details of the underlying mechanisms for accumulating the information for providing that service. A basic service-oriented architecture includes a service requestor or consumer and a service provider. The service consumer typically sends a service request message over a network to a service provider and the service provider returns a response message to the service consumer. The service provider may also be a service consumer as well.
Examples of services-oriented architectures include Distributed Component Object Model (DCOM), Object Request Brokers (ORBs) based on the Common Object Request Broker Architecture (CORBA®) specification, web services, and the like. The term web service refers to a collection of technologies and specifications that support interoperable machine-to-machine interaction over a network. For example, a web service defines communication between the requestor and the server. It has an interface described in a machine-processable format such as Web Services Description Language (WSDL). Other systems interact with the Web service in a manner prescribed by its description using Simple Object Access Protocol (SOAP) messages, typically conveyed using hyper text transfer protocol (HTTP) using extensible markup language (XML) serialization in conjunction with other web-related standards. The Web Services Description Language (WSDL) provides grammar and syntax for a service provider to describe its service. The description may be published in a directory of services. A web services policy framework (WS-Policy), developed by a consortium of companies including IBM and Microsoft, provides extensible grammar for expressing the capabilities, requirements, and general characteristics of entities in a services based system. WS-Policy defines a framework and a model for the expression of these properties or service requirements as policies. For example, when a requestor requests service from a provider, the provider may require the requester to communicate with it over a specific authentication policy such as Kerberos. In another example, a service that provides streaming media, such as video, might require that the requestor be able to buffer a certain volume of data. In another example, a service might require a requestor to communicate over a network with a particular set of minimum latency and jitter characteristics. The WS-Policy specifies grammar and language which allows the provider to communicate these service requirements to the requestor over lower level protocols such as HTTP, transaction control protocol/internet protocol (TCP/IP), and the like.
A problem arises, however, when a requester determines it cannot fulfill the service requirements specified by the service provider. For example, the requestor may only know how to be authenticated by using the Public Key Infrastructure (PKI) instead of Kerberos. Typically, the requestor's only option is to find another service provider which offers the same service which has service requirements that the requestor may satisfy. Such a search may needlessly expend computer and network resources without ever finding a match of service requirements that the requestor can satisfy. Or, in some cases, where an alternate service is found, the alternate service may be less desirable, for example, due to its lower performance. For more information on finding service providers based on a requested service policy, please refer to U.S. Patent Application Publication 2004/0098606 entitled “SYSTEM, METHOD AND PROGRAM PRODUCT FOR OPERATING A GRID OF SERVICE PROVIDERS BASED ON A SERVICE POLICY” published May 20, 2004.
Some prior approaches attempt to alleviate the problem by providing service brokers in the network. In these approaches, service providers register with these service brokers. When a requester wants a service, these service brokers initially will attempt to find service providers which match the requirements of the requestor. Since the requirements of the requestor drive the service broker's search, in some cases, a service provider matching the requestor's requirements cannot be found. Or, in other cases, the match, while acceptable, is not optimal.